Over at cucumber/common#250 there is a discussion about adding a Rule keyword to Gherkin. This pull-request should not be merged - it's only here for illustration and discussion.

I wanted to get a feel for what this would be like, so I wrote a simple RSpec example for our familiar Shouty codebase.

If we were to add the Rule keyword to Gherkin, we could write this instead:

Feature: Hear Shout

  Rule: Shouts have a range of 1000m

    Scenario: In range shout is heard
      Given Lucy is at 0, 0
      And Sean is at 0, 900
      When Sean shouts
      Then Lucy should hear Sean

    Scenario: Out of range shout is not heard
      Given Lucy is at 0, 0
      And Sean is at 0, 1100
      When Sean shouts
      Then Lucy should hear nothing

This brings the Gherkin structure closer to Example Mapping.

It also makes it possible to (optionally) test the rule with a property based tool:

Rule('Shouts have a range of {int}m') do |range|
  property_of {
    shouter_loc  = Coordinate.new(*Rantly(2) { range(0, 2000) })
    listener_loc = Coordinate.new(*Rantly(2) { range(0, 2000) })
    guard shouter_loc.distance_from(listener_loc) < range

    [shouter_loc, listener_loc]
  }.check { |shouter_loc, listener_loc|
    shouty = Shouty.new
    shouty.set_location('shouter', shouter_loc)
    shouty.set_location('listener', listener_loc)
    shouty.shout('shouter', listener_loc)
    expect(shouty.messages_heard_by('listener').length).to eq(1)
  }
end

Apart from changing the Gherkin grammar to allow for this, I don't think this would require a massive change in Cucumber itself. The rule can be thought of a 1-step scenario that (conventionally) uses a property based testing in its body.